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MIGRATION DE DIFFERENTS LANGAGES SOURCES VERS UN SUPPORT D*EXECUTtON. 

_ L'Inventlon execute automatiquement dans un unique 
support d'ex6cutjon plusleurs programmes (PI, FN) 6crits 
en des langages sources (LS1 , LSN) auxquels des supports 
dex^cution respectifs (Sbl, SEN) sont d^di^s, sans con- 
tralndre un programmeur k un langage source unique pour 
un type de support d'ex^cution respectif. Chaque program- 
me est compile (E1 , E2; E12) en un programme exprim6 en 
un langage Intenn6dlalre (LI) representatif d'un sous-en- 
sembie minimal des langages sources. Dans un moven de 
traitement de donn6es tel qu'une carte k puce (GU; CS), un 
support ^execution (SEU; SES) est d6di6 au langage inter- 
mediaire. Le programme en langage interm6diaire estchar- 
avec une biblioth^que de programmation respective 
(BPn) adaptant le iangage source respectif au langage In- 
termedlaire afin d'ex^cuter te programme en langage inter- 
mediaire dans le support d'execution (SEU; SES). 
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Migration de diff6rents langages sources vers un 
support d * execution 

L' invention concerne les cartes k puce, dites 
5 6galement cartes k microprocesseur, et plus 
g6n6ralement des moyens de traitement de donn§es 
ouverts programmable s 4 microprocesseur pouvant etre 
charges par des applications Scrites dans des 
langages de programmation 4volues. 

10 L' invention est plus particuliferement dirig6e 

vers l'h6terog6n6it6 de ces diff6rents langages qui 
ne permet pas d'6crire une application dans un 
langage particulier et de la faire ex6cuter par 
n'importe quel moyen de traitement de donn6es 

15 programmable ; 1 ' invention est par cons6quent dirig6e 
6galement vers I'ouverture de moyens del traitement de 
. donn6es . L' invention concerne 1 ' interop6rabilit6 
d' applications Sorites pour des moyens de traitement 
dei donn6es prograromables, t el les que JAVA Card, 

20 WINDOWS for SMART Card, MultOS (marque d6pos6e) , etc. 
L' interoperability est assortie d' exigences en terme 
de securite. 

Dans le domalne des cartes d puce programmables, 
25 chaque langage source de programmation utilis6 pour 
fecrire une application destinSe 4 §tre charg6e dans 
une carte est fortement li§ d un support d' execution 
particulier g6n6ralement ayant un caractSre logiciel, 
comme une machine virtuelle, mais aussi ayant un 
30 caractSre materiel, comme un microprocesseur. 

Pour pouvoir charger un programme dans une carte 
a puce, le programme 6crit dans un langage source 
donn6 est compile, puis est chargfe dans la carte h 
puce spScialement destin6e A accueillir des 
35 programmes ecrits dans le langage source donn6. La 
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carte regoit le programme compile et 1* execute au 
moyen d'un support d'exfecution sp6cialement d6di6 k 
l'ex6cution de programmes initialement 6crits dans le 
langage source donn^. 

5 Corame montre a la figure 1, des cartes i puce Cn 

contenant chacune un support d' execution respectif 
SEn diffSrents de ceux SEl i SEN d'autres cartes ^ 
puce CI a CN, avec I'entier n compris 1 et un nombre 
entier N grand d^signant un nombre pr6d6termin6 de 

10 langages sources LSI k LSN, ne peuvent ex6cuter des 
programmes applicatifs Pn que si elles sont 
prograram6es dans le langage source respectif LSn. 
Pr6alablement k la compilation du programme 4 
charger, celui-ci subit une verification de code pour 

15 contrdler que le programme k charger n'enfreint pas 
des propri6t§s de s^curitS fournies par le support 
d'ex§cution SEn associ^ au langage source LSn. 

En fait dans un tel ensemble de cartes, un 
programme Pn d§velopp6 dans un langage source LSn 

20 donne est intimement 116 au support d' execution cible 
SEn au motif que : 

1) les structures de donn6es et les operations 
fournies par le langage source LSn sont sp6cialis6es 
pour §tre complices vers uiie representation optimisSe 

25 en taille et en Vitesse pour le support d' execution 
SEn dedie au langage source LSn ; 

2) des bibliotheques de programmation BPn 
fournies avec le langage source LSn sont en general 
correiees au langage source et optimis6es pour le 

30 support d' execution SEn dedi6 au langage source ; 

3) la verification du programme Pn avant qu'il 
ne soit charge dans une carte Cn est intimement liee 
aux proprietes de s6curite assur6es par le support 
d' execution cible SEn. 

35 
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Cette forte liaison entre un langage source LSn 
et son support d'ex6cution SEn se concretise dans vine 
chaine de verification, compilation et chargement 
CVCCn. Cette chaine g6re une transformation d'un 
5 programme Pn 6crit dans un langage source de haut 
niveau en une forme compacte et prete t etre ex^cutee 
de facon efficace par le support d' execution SEn 
dSdie au langage source LSn. 

10 Le probl6me g§n6ral A I'origine de 1' invention 

est de lier des programmes 6crits avec n^importe 
lequel de diff^rents langages sources LSI k LSN, h 
diffferents supports d' execution SEl i SEM, M etant un 
entier quelconque 6gal ou different de I'entier Ce 

15 probleme g6n6ral peut Stre decompose en les trois 
sous-probiemes suivants. 

Selon le premier sous-probieme SPl, il s'agit, 
par exemple, de faire ex6cuter un programme P ecrit 
avec un langage source LSn sur un support d' execution 

20 SEm dedie k un langage source donne LSm, avec 
I'indice m compris entre 1 et M. 

Le deuxieme sous-probieme SP2 consiste d charger 
des programmes PI k PN ecrits respectivement avec 
differents langages sources LSI k LSN dans un support 

25 d' execution coromun SEm capable d'apporter k ces 
differents programmes un environnement efficace en 
terme de taille memoire, de rapidite d' execution, de 
leurs bibliotheques de programmation BPl A BPM et de 
leurs proprietes de securite. 

30 Le troisieme sous-problfeme SP3 vise = i faire 

coexister differents programmes PI A PN ecrits 
respectivement en differents langages sources LSI k 
LSN au sein d'un support d' execution commun SEm. Pour 
le troisieme sous-probieme, il est recommande de 

35 traiter la securite des programmes PI A PN issus de 
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diff^rents environnements de pf ogr aroma t ion et plac6s 
dans sur un m§me support physique. 

Pour la resolution des trois sous-probl6mes SPl, 
SP2 et SP3 qui revient a r^soudre 1' interoperability 

5 de diff^rentes applications fecrites par exemple pour 
des cartes ^ puce prograrnmables avec conservation de 
la s6curite et des ni6canlsines de protection et 
d* interaction, I'hoinine du metier pourrait envisager 
les trois categories de solutions suivantes qui sont 

10 cependant peu satisfaisantes. 

La premiere solution, la plus simple et la plus 
utilisfee, consiste Sl r66crire un programme Pn 6crit 
dans un langage source LSn d6di6 4 un support 

15 d' execution SEn implante dans une carte h puce Cn, en 
des prograraiaes Pnl et PnM ecrits respect ivement par 
exemple en des langages sources LSI k LSM dedies & 
des supports d' execution SEl et SEM implantes dans 
des cartes k puce CI et CM, comme indique par des 

20 operations d'ecriture Wl et WM dans la figure 2, 

La premiere solution present e comme principal 
inconvenient une lourde et fastidieuse tache prise en 
charge nianuellement par un programmeur, consistant en 
la reecriture de I'algorithme du programme Pn en le 

25 programme Pnl, PnM qui doit etre adaptee aux 
structures de donnees et bibliotheques de 
programmation differentes BPl, BPM pour le nouveau 
langage source LSI, LSM« De plus, les mecanismes de 
securite fournis par chacun des nouveaux supports 

30 d' execution SEl et SEM necessitent de refaire 
certifier le code du programme reecrit Pnl, PnM. 

La premiere solution ne traite uniquement que le 
sous-probieme SPl et ainsi ne r6sout que tr6s 
partiellement le probieme de 1' interoperabilite de 

35 programmes. De plus, si un autre langage source 
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associe ^ un support d' execution autre que les 
supports execution SEl, SEn et SEM apparalt dans 
une nouvelle carte, il faut reprendre tous les 
anciens prograinmes 6crits dans le langage source 
5 initial LSn pour les r§6crire avec ledit autre 
langage source. 

La deuxiSme solution comporte une compilation 
crois6e* 

10 En r6f6rence ^ la figure 3, soit par exemple . 

deux prograinmes PI et P2 qui sont 6crits en des 
langages sources respectifs LSI et LS2 auxquels sont 
initialement d6dies deux supports d'ex6cution 
respectifs SEl et SE2 dans deux cartes ^ puce CI et 

15 C2 ; apr6s avoir subi des compilations dans des 
chalnes de verification/ compilation et chargement 
CVCCl et CVCC2, ils peuvent §tre ex6cut6s 
classiquement chacun dans les supports d* execution 
SEl et SE2. Toutefois, les programmes PI et P2 

20 doivent etre ex6cut6s dans les supports SE2 et SEl 
respectivement/ et Sgalement tous les deux dans un 
troisi^me support d' execution SE3 contenu dans une 
troisidme carte k puce C3 et d6di6 k un troisi^me 
langage source LS3, 

25 Pour ex6cuter le programme PI, ou P2, dans les 

supports d' execution cibles SE2 et SE3, ou SEl et 
SE3, autre que celui SEl, ou SE2, d6di6 au langage 
source initiale LSI, ou LS2, le programme PI, ou P2, 
subit des compilations dans des chalnes 

30 additionnelles de verification, compilation et 
chargement CVCC21 et CVCC31, ou CVCC12 et CVCC32. 

Comparativement k la premiere solution, la 
deuxi^me solution ne n6cessite plus de la part d'un 
programmeur de r66crire manuellement les programmes, 

35 mais requiert la mise k disposition de trds 
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nombreuses chaines de verification, compilation et 
chargement CVCC12^ CVCC21, CVCC31, CVCC32. Plus 
g6n§ralement, pour N langages sources LSI a LSN et M 
supports d' execution SEl ^ SEM, N*M chaines de 
5 verification, compilation et chargement sont 
nScessaires. Ces chaines impliquent par leur nombre 
et leur complexity un investissement materiel, 
Ipgiciel et humain considerable. 

Outre cet inconvenient majeur, la deuxidme 
10 solution presente les inconvenients suivants : 

- mauvaises performances en taille memoire et 
rapidite d' execution des programmes ainsi generes, 
les supports d' execution dans lesquels ils sont 
executes n'etant pas a priori convenablement adaptes 

15 aux structures de donn6es, operations et 
bibliotheques de programmation des langages sources 
LSI et LS2 utilises pour ecrire ces programmes ; 

realisation de chaines de verification, 
compilation et chiargement egal en nombre aux supports 

20 d' execution cibles existants SEl k SEM lorsqu'un 
nouveau langage source apparalt, et reciproquemeht 
egal en nombre aux langages sources existants LSI A 
LSN lorsqu'un nouveau support d' execution apparalt ; 

- pour le deploiement des programmes, chargement 
25 pr6alable de tous les postes de teiechargeraent avec 

les programmes dotes des codes compiles et certifies 
pour les differents supports d' execution SEl a SEM, 
ce qui rend la deuxiSme solution encore plus complexe 
et coQteuse. 

30 La deuxieme solution ne traite uniquement que le 

sous-probl6me SPl mais de manidre automatisee 
comparativement k la premiere solution, et ainsi ne 
resout que tres partiellement le probieme de 
1' interoperabilite, De plus, si un autre langage 

35 source associe A un support d' execution autre que les 
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supports d'ex6cution SEl k SEM apparalt dans une 
nouvelle carte, il faut passer tous les programmes 
initiaux PI k PN dans de nouvelles chalnes de 
verification, coiapilation et chargement produisant 
5 des codes certifies pour ledit autre support 
d' execution. 

La troisiSme solution suggSre des cartes h puce 
CP qui contiennent chacxine plusieurs supports 

10 d' execution, par exemple trois supports d' execution 
SEl, SE2 et SE3, comme montre k la figure 4* Ainsi, 
des programmes PI, P2 et P3 ecrits respect ivement 
avec des langages sources differents LSI, LS2 et LS3 
peuvent etre charges dans la carte CP a travers des 

15 chalnes respectives de verification, compilation et 
chargement CVCCl, CVCC2 et CVCC3. La carte CP apporte 
k chaque programme PI, P2, P3 exact ement les mSmes 
fonctionnalites que s'il etait charge 
individuellement sur une carte ne comportant que le 

20 support d' execution SEl, SE2, SE3 dedie au langage 
source respectif ^LSl, LS2, LS3. 

La troisieme solution conserve avahtageus ement k 
I'identique les chalnes de verification^ compilation 
et chargement CVCCl, CVCC2 et CVCC3 respectivement 

25 associees aux langages sources LSI, LS2 et LS3 et 
permet aussi de resoudre le sous-probieme SP2. 

Neanmoins, la troisieme solution presente 
1 ' inconvenient majeur d'etre actuellement d'autant 
plus irrealisable que le nombre de supports 

30 d' execution differents 4 implanter dans la carte et 
representant chacun une quantite importante de code 
est eieve. La memoire necessaire k la troisieme 
solution n'est pas concevable actuellement dans une 
carte A puce et serait en pratique plus utilement 
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exploitable pour ia6moriser davantage de donnSes et de 
programmes par exemple. 

L'objectif principal de l^invehtion est de 
5 fournir un proc§d§ pour ex6cuter automat iquement 
plusieurs programmes 6crits dans des langages sources 
diff6rents dans un unique support d'exfecutiou/ sans 
contraindre un programmeur k un langage source unique 
pour un type de support d 'execution respectif* Get 
10 objectif principal revient A rfesoudre les trois sous- 
problSmes d6finis ci-dessus SPl, SP2 et SP3, c'est-A- 
dire l'interop6rabilit6 des programmes en diff6rents 
langages sources qu'aucune des trois solutions 
pr6sent6es ci-dessus ne rSsoud compldtement . 

IS 

A cette fin, le proc6d6 de migration de 
plusieurs programmes 6crits respectivement en des 
langages sources auxquels des supports d^ execution 
respectifs sont d6dies, vers un moyen de traitement 
20 de donnSeS/ est caract6ris6 en ce qu'il comprend les 
etapes de : 

- compiler chaque programme en un programme 
respectif exprim6 en un langage intermfediaire 
representatif d'un sous-ensemble minimal des langages 

25 sources, 

- fournir dans le moyen de traitement de donnfees 
un support d' execution pr6d6termin6 dSdi6 au langage 
intermfediaire^ et 

- charger le programme respectif en langage 
30 interm^diaire dans le moyen de traitement de donn^es 

avec une bibliothSque de programmation respective 
adaptant le langage source respectif au langage 
intermediaire afin d'ex§cuter le programme en langage 
interr^iediaire dans ie support d^'ex6cution 
35 pr6d6termin6 . 
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L" invention repose sur la recherche d'un support 
d' execution qui est initialement le plus petit 
d§nominateur commun present dans . des supports 
d' execution de moyens de traitement de donn6es k 

5 microprocesseur pr6d6termin6es ; par exemple les 
supports d'ex6cution sont contenus dans des cartes k 
puce connues de differents types, c'est-A^dire dont 
les programmes sont 6crits en des langages sources 
diffferents. L» invention offre done les avantages de 

10 la troisi^me solution presentee pr6c6demment, 
sugg6rant de mettre dans un moyen de traitement de 
donnfees k microprocesseur 1' ensemble de tous les 
supports d'execution possibles. Mais au lieu d'exiger 
une taille de mfemoire considerable, voire 

15 irr6alisable, 1' invention n'implante qu'un support 
d' execution reduit dedi6 A un langage interm6diaire 
minimal/ mais flexible dans chaque moyen de 
traitement de donndes, tel que carte k puce. En temps 
que tel, le langage intermfediaire n*est associ^ k 

20 aucun langage source particulier, et sert de langage 
de base pour servir de cible k plusieurs langages 
sources. La m6moire requise pour implanter le langage 
interm^diaire est ainsi r^duite et par consequent 
1' execution d'un programme est plus rapide que dans 

25 la troisiSme solution sugg6r6e ci-dessus. 

L' invention met ainsi en oeuvre la combinaison : 
d'un langage intermfediaire capable de 
representer aussi bien les programmes issus de 
differents langages que les ' bibliotheques de 

30 programmation et les proprietes de securite 
specifiques necessalres k leur bdn fonctionnement, et 
- d'un support d' execution dedi6. au langage 
intermediaire, mais capable d'etre reconfigure pour 
s' adapter au mieux aux exigences de chaque langage 
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aussi bien en terme d'environnement de travail qu'en 
terme de contrdle de s6curit6 des applications. 

Selon une variante de 1' invention, I'etape de 
5 compiler peut comprendre les etapes de : 

- compiler le programme en un programme compil6 
en un langage machine auquel le. support d' execution 
respectif est d6di6, et 

- convertir le programme compil6 en le programme 
10 respectif exprim6 en langage interm6diaire. 

Cette variante peut fit re d'intfirfit pour un 
developpeur de programme A partir du rfisultat compilfi 
d'un programme pour produire le code en langage 
intermfidiaire. L'outil qui permet cette operation est 

15 un convertisseur . II remplace les instructions du 
support d' execution respectif associe au langage 
source par des operations Sorites en langage 
intermfidiaire . 

Selon un autre aspect de 1' invention, le procfidfi 

20 peut comprendre une fitape, avant I'fitape de charger, 
pour extraire des informations de validation du 
programme respectif en langage intermfidiaire, et une 
6tape, apr6s .l'6tape de charger, pour verifier les 
informations de validation extraites dans le support 

25 d' execution predetermine - 

Selon une autre variante, le support d' execution 
predetermine peut fitre analogue & I'un des supports 
d' Execution. Bien que globalement moins avantageuse 
30 que la realisation de base de 1' invention, cette 
variante peut fitre intfiressante lorsque les langages 
sources sont des langages ayant subis des evolutions 
et modifications analogues • 
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De pr6f6rence, le langage interm^dlalre est 
extensible, tandis que le support d' execution 
pr^dSterminS est extensible ou non extensible. Au 
moins l*un des langages sources et le langage 
5 intermfediaire sont avantageusement des langages 
orient6s objet. 

En pratique, le procede peut coroprendre une 
Stape de lire des caract^ristiques du support 
d' execution pred6termin6 par un serveur qui ensuite 
10 effectue I'etape de compiler. 

Le moyen de traitement de donn6es est par 
exemple une carte d puce. La carte k puce peut Stre 
une carte d'identite d'abonne incluse dans un 
terminal radiot616phonique mobile . 

15 

D'autres caract6ristiques et avantages de la 
pr6sente invention apparaltront plus clairement d la 
lecture de la description suivante de plusieurs 
realisations pr6f6rees de 1' invention en ref6rence 

20 aux dessins annexes correspondants dans lesquels : 

- la figure 1 dSjd comment^e est un diagramme de 
production et d' execution de plusieurs programmes 
respectivement ecrits en des langages sources 
diff6rents pour des supports d' execution respectifs ; 

25 - les figures 2, 3 et 4 d6ja comment6es sont des 

diagrammes de premiere, deuxi^me et troisidme 
solutions partielles a l'interop6rabilit6 de 
programmes en langages sources diff6rentS/ sugg^r^es 
par la technique ant^rieure, respectivement ; 

30 - la figure 5 est un diagramme de production et 

d' execution de plusieurs programmes 6crits en des 
langages sources diffSrents pour gtre executes dans 
un support d' execution d6di6 a un langage 
intermSdiaire et contenu dans une carte 4 
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microprocesseur, selon une realisation pr6f^r6e de 
!• invention et des variantes de celle-ci ; 

- la figure 6 montre des stapes de compilation 
et conversion d'un programme 6crit en un langage 

5 connu, en un langage intermediaire selon 1' invention; 

- la figure 7 est une 6tape de compilation d'un 
programme 6crit en un langage connu, analogue au 
programme de la figure 6, directement en langage 
intermediaire ; 

10 - la figure 8 montre une 6tape d' adaptation 

d'une sequence en langage intermediaire avant 
execution selon la premiere realisation ; 

- les figures 9 et 10 montrent des conversions 
d'une sequence ecrite en un langage de machine 

15 virtuelle en des sequences sans et avec extension du 
laingage intermediaire, respectivement ; et 

- la figure 11 montre une adaptation d'une 
sequence en langage intermediaire avant execution, 
selon une variante de 1' invention. 

20 

En reference A la figure 5, N programmes 
applicatifs PI ^ PN sont susceptibles d'etre ecrits 
respectivement en des langages sources LSI k LSN a 
priori differents dans un serveur d' application SER. 

25 Les langages sources sont parfois appeles "langages 
evolues" ou "langages de haut niveau". 

Selon une realisation prefer6e de 1' invention, 
le precede de migration a pour object if de faire 
migrer n'importe lequel programme Pn ecrit dans le 

30 langage source respect if LSn vers un support 
d* execution universel SEU selon 1* invention, contenu 
dans un moyen de traitement de donn6es correspondant, 
tel qu'une carte 4 puce programmable "universelle" 
CU, comme defini ci-apres. 
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Comiae illustr^ ^ gauche dans la figure 5/ le 
proc6d6 de migration comprend essentiellement quatre 
stapes El ^ E4, apr^s une Stape Initiale de 
d§veloppement et de fourniture EO d'un programme Pn 
5 dans le langage source, respectif LSn, avec 1 ^ n :S N. 

Les programmes PI ia PN ont 6t6 d6velopp6s dans 
un serveur SER reli6 A lin terminal TE contenant la 
carte CU A t ravers un r^seau de t616communications 
RES. Par exemple, le terminal TE est un terminal 

10 bancaire reli6 au serveur par des lignes loupes ou 
sp6cialis6es du r6seau RES ; selon un autre exemple, 
le terminal TE est un terminal radiotelfephonique 
mobile de type GSM reli6 au serveur SER par un r^seau 
de radiot616phonie cellulaire numferique RES, le 

15 serveur 6tant reli6 & des commutateurs du service 
mobile (MSG) d travers le r§seau de signalisation du 
r6seau de radiot616phonie, et la carte CU etant une 
carte d' identity ,d'abonn6 de type SIM (Subscriber 
Identity Module) amovible du terminal TE. 

20 

A l'6tape El, le serveur SER interroge le 
support d' execution SEU dans la carte CU de maniSre & 
y lire et enregistrer des caract6ristiques d6ja 
pr6sentes du support d'ex6cution. Puis le programme 

25 Pn en langage source LSn est compile en un programme 
compile PCn exprim6 en un langage machine auquel est 
d6di6 le support d' execution cible respectif SEn. Un 
compilateur rfealisant l'6tape El est un programme 
installe dans le serveur SER. Puis & l*6tape E2, le 

30 programme compilfe PCn est converti en un langage 
interm6diaire LI selon 1' invention. Comme le 
compilateur, un convertisseur de langage est un 
programme implements dans le serveur SER et realise 
l'6tape E2. 
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Le langage intermSdiaire LI poss^de notamment 
les deux propriStSs suivantes : 

- extensibilit6 : le langage LI est capable 
d'enrichir le champ de coramandes 616mentaires pour 
5 exprimer ef f icacement des programmes issus d'autres 
langage s ; 

typage fort : comme il est connu, les 
m6canisroes de s6curit6 du code par typage constituent 
le grain le plus fin possible pour un contrdle de 

10 s6curit6 ; les propri6t6s de s6curit6 de chaque 
langage sont alors sp6cifi6es & partir du module 
initial present dans la carte ; le langage 
intermfediaire LI permet un contrdle par typage 
extensible d la maniSre des types ou des classes des 

15 langages A objet, 

Le langage interm6diaire LI ne contient qu'un 
nombre trSs limit6 d' instructions constituant un 
sous-ensemble minimal repr6sentatif des langages 
machines des differents supports d'ex6cution SEl ^ 

20 SEN, Une bibliothSque de prograramation additionnelle 
est utilis6e par le convertisseur de langage h 
I'^tape E2 pour §viter que chaque op6ration 
61§mentaire pour le syst^me d'ex6cution SEn ne soit 
remplac6e par un ensemble d' instructions pour le 

25 support d' execution universel SEU. Cette precaution 
limite les risques d' augmentation du volume en 
m6moire des programmes chargfes dans la carte CU. 

La figure 6 montre selon un premier exerople les 
30 Stapes El et E2 pour un programme en langage source, 
tel qu'un segment de code PJ exprim^ dans le langage 
source orients objet JAVA relatif A une reception 
dans la carte d'un message transmis par le serveur 
SER. ! 
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L'6tape El effectue classiquement la compilation 
du segment PJ ien un programme binaire compil6 PJC 
sous un format appel6 pseudo-code (Byte Code) qui est 
capable de fonctionner sous un support d' execution 

5 SEJ, c'est-a-dire un micro-ordinateur ayant 
impl6ment6 le concept de la machine virtuelle JAVA. 
Classiquement, chaque instruction sous le langage 
JAVA donne naissance ci plusieurs instructions du 
langage de la machine virtuelle. 

10 Puis k I'^tape E2, le m6canisme de la conversion 

ne se limite pas k une substitution instruction par 
instruction des pseudo-codes JAVA par des pseudo- 
codes du langage interm^diaire LI, mais convertit une 
succession d' operations ^l^mentaires dans le 

15 programme compile PJC en une sequence diffferente PJLI 
en langage intermediaire, en d(&terminant des 
argiaments d'appels de fonctions par exeitiple. Cette 
conversion etant effectuee k l?ext§rieur de la carte 
CU, il est possible d'implanter des techniques 

20 d' optimisation et de transformation utilis^es dans 
les cbmpilateurs. La conversion k l^^tape E2 garantit 
I'efficacitg du code en langage LI transmis k la 
carte, quel que soit le langage source utilise. De 
plus, la conversion de langage contribue k produire 

25 des 616ments de preuve du bon fonctionnement du 
langage LI que la carte CU utilise pour contrdler la 
viability du programme ; k 1' issue de l'6tape E2, le 
convertisseur de langage fournit des informations de 
typage utiles k la carte pour verifier la viability 

30 du programme. • 

Selon un deuxidme exemple, la figure 7 montre un 
segment de code PC exprimS dans le langage C et 
correspondant k une d§claration d'un tableau de 
travail, comme pour le segment de code PJ en langage 

35 JAVA montr6 k la figure 6. Apr6s l'6tape de 
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compilation El pour compiler class iquement le segment 
PC destine k un support execution d^di6 au langage 
machine pouvant exScuter un prograiame en langage 
I'etape E2 convertit le segment correspondant en 
5 langage machine en une s6quence PCLI exprim6e dans le 
langage intermediaire LI. 

En langage intermediaire LI, la sequence PCLI 
est identique ^ la sequence PJLI : elles comprennent 
les mSmes variables et constantes ainsi que des 

10 coramandes et operations exprim§es de la mfime maniSre, 
excepts I'Scriture du d6clenchement d'une exception 
en fin de sequence propre au langage source initial, 

Le langage intermfediaire LI selon 1' invention 
est ainsi adaptable. Toute operation ou commande 

15 selon les exemples montrSs aux figures 6 et 7 est 
exprim6e sous la forme d*un message applique A un 
objet. Comme pour un langage connu ori.ent6 objet, de 
nouveaux messages dans le langage intermediaire 
peuvent etre d6finis k tout moment. 

20 

La figure 5 montre une deuxi§me variante de la 
premiere realisation, illustrfee en haut et a droite 
en trait pointilie, relative par exemple & la 
production du programme PN initialement exprim6 dans 

25 un langage source LSN. Pour cette deuxiSme variante, 
les etapes de compilation et conversion El et E2 sont 
remplac6es par une Stape de compilation £12 qui 
compile le programme PN en langage source LSN en un 
programme compile directement exprim6 dans le langage 

30 intermediaire LI qui est ensuite v6rifi6 et charge 
dans la carte & puce CU S I'etape E3. 

Selon 1' exemple montr6 & la figure 7, I'etape 
E12 convertit directement le segment PC en langage C 
en la sequence PCLI en langage LI. 



35 
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Ensuite/ en revenant k l*&tape E3 dans la figure 
5, le programme exprimS en langage interm^diaire LI 
suit une chalne de verification et chargement CVG 
afin qu'il soit vSrifi^ et t§16charg6 dans la carte k 

5 puce cible CO. La chalne CVC est au moins en partie 
et de preference totalement installee dans la carte 
CU. L' autre partie de la chalne CVC concerne 
notamment la verification dynamique de 1' execution du 
programme en langage intermediaire et est installee 

10 soit dans le serveur SER, soit dans un terminal TE 
recevant la carte. 

Un mecanisme de verification et/ou d* adaptation 
dans la carte CU 4 l'6tape E3 transforme le code regu 
dans la carte et exprime en langage intermediaire LI 

15 sous la forme d'un programme binaire directement 
executable dans le langage intermediaire. Des 
informations de validite du programme en langage 
intermediaire, relatives notamment d la securite, au 
typage et au confinement, peuvent etre extraites du 

20 programme et etablies dans le terminal TE lors de 
I'etape E3 et verifiees par la carte apr6s le 
chargement du programme dans la carte. Si la 
verification echoue, le programme est invalide. Cette 
verification assure I'efficacite de I'environnement 

25 dans lequel le programme est utilise, en accord avec 
le sous-probieme SP2. 

Les transformations effectuees lors du 
chargement d I'etape E3 peuvent §tre minimes et etre 
reduites A un m6canisme d' edition de lien propre au 

30 milieu des cartes ^ puce. 

L*etape E3 a pour but de completer in situ dans 
la carte, le travail effectue aux etapes El et E2, ou 
a I'etape E12. Le mecanisme de verification et/ou 
d' adaptation convertit compietement le code regu et 

35 le transforme en un programme executable par le 
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support d' execution universe! SEU dans la carte. 
Cette conversion a pour, but de rendre le code plus 
efficace en le soumettant statiquement d des 
controles de securite qui, lorsqu'ils sont executes 
5 dynamiquement/ jpSnalisent fortement le temp's 
d' execution des programmes. En pratique, le m6canisme 
d' adaptation embarqu6 dans la carte CU peut effectuer 
un travail important qui engendre un programme 
directement ex6cut6* par le support d'ex6cution SEU, 

10 c'est-a-dire le microprocesseur present dans la 
carte. La figure 8 illustre un exemple du traitement 
effectu6 par le m6canisme d' adaptation a I'etape E3 ^ 
partir d'une sequence en langage intermediaire PLI, 
analogue a la sequence PJLI, PCLI pour fournir une 

15 s6quence adapt6e PAD. 

A l*etape E4, le programme en langage 
intermfediaire LI est install^ dans la carte CU qui 
est destinfee d supporter directement le langage 

20 interm6diaire LI. La carte SU possSde un m6canisme 
d' adaptation sp6cifique. 

La carte a puce CU qui est programmable, c'est- 
4-dire qui accueille des programmes tout au long de 
son cycle de vie, contient le support d'ex6cution SEU 

25 d6di6 au langage interm6diaire LI. Ainsi les 
programmes PI d PN 6crits dans les divers langages 
sources LSI d LSN coexistent au sein de la m§me carte 
CU qui n'est pas sp6cif iquement d6di6e d l*un des 
langages sources LSI k LSN, mais qui est capable 

30 d'h6berger diff6rents programmes 6crits dans 
diff6rents langages sources, ce qui resout le sous- 
problSme SP2. 

Le support d' execution universel SEU ne contient 
qu'un sous-ensemble restreint des supports 

35 d' execution SEl A SEN des programmes initiaux PI it 
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PN. L'6tape E3 charge des biblioth§ques de 
programmation BPn en mfime temps que chaque programme 
en le langage interm^diaire LI afin d' adapter h 
l*etape E4 le langage source LSn au langage 

5 . intermfediaire et ainsi ex6cuter le programme initial 
Pn dans le langage intermSdiaire. Des propri^tSs de 
s6curit6 sp6cifiques au langage interm6diaire sont 
import^es "par dessus** celles existantes dans le 
support d'ex6cution universel SEU. L' architecture du 

10 support d' execution universel SEU dans la carte CU . 
considdre cet aspect pour fournir aux programmes 
hebergSs un environnement efficace en taille m^moire 
et rapidit(§ d' execution tout en maintenant les 
propri6t6s de s6curit6/ ce qui r6sout le sous- 

15 probl§me SP3. 

Le support d' execution universel SEU plac6 dans 
. la carte CU et supportant 1' execution du langage 
interm6diaire LI est : 

adaptable pour accepter de nouvelles 

20 bibliothfeques de programmation pour chaque nouveau 
langage source supports afin d'ex6cuter le programme 
initialement Scrit dans le nouveau langage dans son 
environnement logiciel ; 

- sOr pour supporter les mecanismes de s6curite 

25 par contrdle des types manipules par les programmes ; 
et 6galement pour accepter la definition de nouveaux 
types afin de d6crire des mfecanismes de s6curite 
associ^s lors du chargement de nouvelles 
bibliothScpies de programmation. 

30 

A l'6tape E4, le m6canisme d' interpretation 
avanc6 de programiae concerne le support d' execution 
lui'-mfime. Le support d' execution SEU logiciel et/ou 
materiel est utilise, commecible pour la generation 
35 de chaque programme executable, pour r6pondre aux 
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pr6occupations des sous-probl6iaes SP2. et SP3. De 
pr6f§rence, le support d' execution SEU comprend un 
jeu d' instructions diffSrent de celui qu'il exploits 
initialement . Cette fonction permet dans I'absolu de 

5 red6f inir ' cpmpletement le support d' execution 
universel SEU pour qu'il puisse directement 
interpreter le code issu d'un langage particulier. Le 
mScanisme d' extension vis6 I'^tape E4 favorise par 
exemple des portions de code issues d'un langage 

10 donnfe et permet surtout d'implanter des operations 
qui dfefinissent une s6mantique diff6rente de celle 
fournie par le support d' execution universel SEU 
initial de la carte CU. 

Le mfecanisme . d' extension est relatif par exemple 

15 & une instruction 616mentaire d'accfes A un tableau, 
qui en langage JAVA d6clehche une exception 
lorsqu'elle sort des limites du tableau, alors que 
dans 1 ' implantation initiale du langage intermSdiaire 
LI, 1 ' instruction elementaire donne acc^s A une case 

20 que Icon que du tableau. Une solution simple consiste A 
transformer une operation OP J en langage JAVA pour 
acc6der k un tableau en une sequence d' operations 
OPLIa en langage intermfediaire LI, sans extension de 
celui-ci, comme montre k la figure 9. Pour 6viter ce 

25 grossissement inutile du code et p6nalisant dans la 
carte, une instruction 616mentaire qui realise 
exactement la semantique equivalente au pseudo-code 
(Byte Code) JAVA est definie dans le support 
d' execution universel SEU, comme montre aux lignes 7 

30 k 10 dans une sequence d' operations OPLIb k la figure 
10. 

Selon une variante de 1' invention, les etapes E3 
et E4 .sont remplacees par des etapes E3d et E4d 
35 montrees k droite de la figure 5. La cible visee est 
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un support d' execution sp6cialis6 SES ayant par 
exemple une architecture matferielle et le cas §ch6ant 
logicielle connue analogue 4 I'un des supports 
d' execution Initiaux SEl k SEN dSdi^s au langage 

5 source LSI k LSN. 

A I'etape E3d, une chalne de v6rification et de 
chargement CVCd est enrichie d'un mfecanisme 
d' optimisation OPT qui g6nftre un code final natif 
efficace qui est optimal A I'exterieur de la carte. 

10 Les contraintes de s6curit6 sont de preference 
rel^chSes puisque les programmes sont produits pour 
des cartes h puce spfecifiques CS line fois pour toute 
et passent par des contrdles de fiabilit6 connus du 
secteur industriel. 

15 La figure 11 montre une adaptation ^ I'etape E3d 

entre une sequence PCId en langage interm6diaire LI 
en une sequence adapt 6e PAd. 

A I'etape E4d, un ensemble de bibliothSques de 
programmation BPn^ BPdn sont portees par le support 

20 d' execution SES pour que le programme issu du 
programme Pn en langage source LSn fonctionne dans 
son environnement . 

Le support d' execution SES selon cette variante 
nScessite la realisation de M chalnes de verification 

25 et chargement, et done l'6criture d'une nouvelle 
chalne CVC fonction d'un nouveau langage. 

Cette variante est moins avantageuse que la 
realisation avec support d' execution "universel" SEU. 
Le support d' execution SES demeure tributaire d'un 

30 support d' execution predetermine SEn, et 
I'inadequation entre la bibliotheque de programmation 
BPn. du langage source LSn et celle attendue pour le 
support d' execution SES programmee k I'origine pour 
un autre langage requiert une capacite de memoire 

35 plus eiev6e et conduit k moins d'efficacite. 
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REVENDICATIONS 

1 - Proc6d6 de migration de plusieurs programmes 
(PI k PN) ecrits respectivement en des langages 

5 sources (LSI & LSN) auxquels des supports d' execution, 
respectifs (SEl i SEN) sont d6di§S/ vers un moyeh de 
traitement de donnSes, caract^risS en ce qu*ll 
comprend les 6tapes de : 

- compiler [El, E2 ; E12) chaque prograrome (Pn) 
10 en un progranaae respect if exprimfe en un langage 

interm6diaire (LI) reprfesentatif d'un sous-ensemble 
minimal des langages sources, 

- fournir (E4) dans le moyen de traitement de 
donn^es (CU ; CS) un support d' execution pr6d§termin6 

IS (SEU ; SES) d6di6 au langage interm^diaire, et 

- charger {E3) le programme respect if en langage 
interm6diaire dans le moyen de traitement de donnfees 
avec une bibliothfeque de programmation respective 
(BPn) adaptant le langage source respectif (LSn) au 

20 langage interm6diaire (LI) afin d'ex6cuter le 
programme en langage interm^diaire dans le support 
d'ex6cution predetermine (SEU ; SES). 

2 - Proc6d§ conforme 4 la revendication 1, dans 
25 lequel IJetape de compiler comprend des 6tapes de : 

- compiler le programme (Pn) en un programme 
compile (PCn) en un langage machine auquel le support 
d'ex6cution respectif (SEn) est dedi6, et 

- convertir (E2) le programme compile (PCn) en 
30 le programme respectif exprim6 en langage 

intermfediaire (LI) • 

3 - Precede conforme 4 la revendication 1 ou 2, 
comprenant une etape, avant I'etape de charger (E3), 

35 pour extraire des informations de validation du 
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programme respectif en langage interm6diaire (LI), et 
une 6tape (E3), apr&s I'etape de charger, pour 
verifier les informations de validation extraites 
dans le support d' execution pr6d6termin6 (SEU, SES),. 

5 

4 - Proc6d6 conforrae k I'une quelconque des 
revendications 1 k 3, dans lequel le support 
d' execution prSd^termin^ (SES) est analogue k I'un 
des supports d* execution (SEl k SEN). 

10 

5 - Proc6d6 conforme k I'une quelconque des 
revendications 1 k A, comprenant \ine 6tape de lire 
des caract6ristiques du support d* execution 
predetermine {SEU; SES) par un serveur (SER) qui 

15 ensuite effectue l'6tape de compiler (El, E2 ; E12) . 

6 - Proc§d6 conforme k I'une quelconque des 
revendications 1^5, dans lequel le moyen de 
traitement de donn6es est une carte k puce (CU, CS) . 

20 

7 ^ Proc6d6 conforme k la revendication 6, dans 
lequel la carte k puce est une carte d'identit6 
d'abonne incluse dans un terminal radio t616phonique 
mobile (TE) . 
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FIG.3 
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FIG.5 



SER 



SiERVEUR 




P2 gcrit en LS2 



P3 6crit en LS3 



Compilation 
LS2^SE 



/ Compilation \ 
V LSN=»L1 / 

El 2 



Conversion 
SE1=»U 



E2 



Conversion 
SEn=>U 



RES 




RESEAU 



TE 




OU 




Code 
pour SEU 









SEU 


BPn pour 
SEn/SEU 


S6curit£ du SEU 



CU 



-E3d 



^CVC+OPT^ 
U=*»SES 

r Code n 

I programme I 
I pour SES I 

BPn pour 




U+LSn I 



r 

I SES 
|^S6curit6 du SEsJ 

CS 



E4d 



2794543 



4/7 

no. 6 



PX 



/♦ Debut tfun programme JAVA pour carte k puce : r&eption dans la carte dHin 
message transmis par le serveur */ 
^ubfic void process(APDU apdu) // declaration dVme procedure JAVA (carte) 

byte[] buflfer, // declaration dhin tableau de travail 

buffer = apdu.getBuflFerO; // bufFer prend le message envoye i carte 

if (buffer[ISO.OFFSET_CLA] != MyApplet^CLA) // dasse de oommande correcte ? 
throw new ISOException( 
^ ISO.SW,CLAjTOTJUPPORTED);//sinonilfaut declcncher unc crreur. 



El. 



PJC 



JAVA -> pseudo-code pour SE Java. 



; » METHOD process compile pour une marchine virtuelle JAVA « 

.method public process(Ljavacard/framework/APDU;)V 
.limit stack 3 , ; nombre de variables de travail 

.limit locals 3 ; nombre de variables locales 

,var 0 is this LClassl ; declaration variable this 

.var 1 is apdu Ljavacard/frameworlc/APDU ; variable apdu 

.var 2 is bufEM- [B ; variable bufFer 



aload_l 

invokevirtual APDU/getBufferO[B 
astore_2 
aIoad_2 
iconst^O 
baload 
sipush204 
ifjcmpeq Labell 



; chargement sur la pile de Targument apdu 
; appel de la methode getBugffer sur apdu 
; Resultat enregistre dans bufFer 
; chargement de la variable bufFer 
; chargement de la valeur OFFSET_CLA=0 
; chargement de bufFer[OFFSET_CLA] 
; chargement de la valeur MyApplet_CLA=204 
; comparaison des valeurs en sommet de pile 



new javacard/framework/ISOException ; creation d'une instance d*exception 
dup ; duplication du sommet de pile 

sipush 28160 ; chargement valeur d'initialisation = SW CLA NOTJ 
invokespecial javacard/framework/ISOException/<init>(S)V ; initialiser 
athrow ; declencher Fexception 

Labell: 

Return ; fin de la methode 

end method 



PJLlr^ 



Conversion pseudo-Code -> LI 



; portion de programme LI desassemble 
. arg I, (apdu : JAVA^APDU} ; un seul argument attendu : apdu 
.Icl 1 , {bufFer : JavaByteArray } ; une variable locale : buffer 



.tmp 1 
.est 1,{0,204,28160) 
bufFer <- apdu getBufFer 
tmpO <- bufFer get At cstO 
tmpO <- tmpO != est! 
jumpif tmpO,Labell 



; une variable temporaire (tmpO) 
3 constantes : cst0=0,cstl=204,cst2=28160 
; 'bufFer' prend le buffer de Tapdu 'apduV 
; charger la valeur de la case OFFSET_CLA de bufFer 
; compare Tegalite de bufFer[OFFSET_CLA] et 204 
; slls sont 6gaux, saut a Labell ^ 
tmpO <- JavaException create cst2 ; creer une exception initialise a 28160 
void <- JavaException throw tmpO ; Declencher Texception cre6e. 
Labell: 
return 
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PC 



/delude <ISOCard.h> /* lilM^rie de d^eloppement pour carte 
#defme MYCARDAPPLY OxCC 

/* D^but d'un programme C pour carte k puce : reception dans ia carte d'un message 
transmis par le serveur */ 

void main(apdu *apdu) /* declaration dWe procedure C (carte) 

{ 

unsigned char ^buffer ; /* declaration d*un tableau de travail 
buffer = getApdu(apdu) ; /* 

if(buffer[ISO_OFFSET_CLA] != MYCARDAPPLY) /♦ classe de conimande correcte ? 

CardExit(SW_CLA_NOT_SUPPORTED) ; 
Return; 

) 



El+E2,ouE12^ 



PCLI 



Compilation classique C -> LI 



; portion de programme LI desassemble 
.arg l,(apdu : ISOCARD__APDUI ; un seul argument attendii ; apdu 
.Icl 1, {buffer : UCharArray } ; une variable locale : buffer 
tmp 1 ; une variable temporaire (tmpO) 

.est 1,(0,204,28 160} ; 3 constantes : cst0=0,cstl=204,cst2=28160 

buffer <- apdu getBuffer ; 'buffer* prend le buffer de Tapdu 'apduV 

TmpO <- buffer get At cstO ; charger la valeur de la case OFFSET_CLA de buffer 

tmpO <- tmpO != cstl ; compare Tegalite de buffer[OFFSET_CLA] et 204 
jumpif tmpO,Labell ; slls sont 6gaux, saut i Labell 

void <- System CardExit cst2 ; Declencher I'exception cr£ee. 
Labell: 
return 
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PLI^ 




PAD^ 


; portion de programme LI 
; desassemble 
.Icl 0 
.tmp 1 
.est 1,(0} 




; portion de code SEU 
; disassemble 
.sstack 0 

\/CfQ/*ir 1 

• VolavK 1 

Jest 1,{0} 


i <- cstO asis 

tmpO <- test toByteArray i 

void <- out apduReponse tmpO 

return 




cload cstO 
sstore i 

sload i 

jsm test\toByteAiTay 






E3 

Adaptation 
dansCU 


dload out 

jvm apduResponse 


ret 



na9 



OPJ 



OPLIa 



, portion de programme JAVA disassemble 
limit stack 2 
limit locals 0 

new array byte 
iconst_3 
iconst_0 
bastore 



Conversion pseudo-code -> LI 



; portion de programme LI desassemble 

.Icl 0 

.tmp 3 

.est 2,(3,0) 

tmpO <- ByteArraynew 

tmpl <- tmpO getSize 

tmpl <- cstO <= tmpl 

jumpif tmp 1 , ArraylsOK 

void <- Exception throws javaOutOfBound 

ArraylsOK : 

void <- tmpO putByteAt cstO,cstl 



2794543 



7/7 



HG. 10 



dPJ 



portion de programme JAVA desassemble 
limit stack 2 
limit locals 0 

new array byte 
iconst_3 
iconst_0 
bastore 



Conversion pseudo-code -> LI adaptable 



OPLIb 



; portion de programme LI desassemble 

.Icl 0 

.tmp 3 

.est 2,(3,0} 

tmpO <- ByteArray new 

tmpl <- tmpO JavaGetByte cstO,cstl 

;(with) 

; ByteArray/JavaGetByte : 

tmpl <- tmpC getSize 

tmpl <- cstO <= tmol 

jumpif tmpl,ArrayIsOK 

void <- Exception throws javaOutOfBound 

ArraylsOK : 

void <- tmpO putByteAt cstO,cstl 



PLId 



1. 



na 11 



PADd 



; portion de programme LI 
desassemble 

.arg l,{apdu:ISOCARD_APDU} 

.Icl 1, {buffer : UCharArray } 

.tmp 1 (tmpO) 

:cst 1,(0,204,28160) 

buffer <- buffer getAt cstO 

tmpO <- buffer getAt cstO 

tmpO <- tmpO != cstl 

Jimipif tmpO,Labell 
void <- System CardExit cst2 creee. 
LabeU: 

return 



7 



E3 

Adaptation 
dansCS 



; portion de code Natif (ARM7TDI) 
; desassemble 

; rO = this ; rl = apdu 
; r2 = buffer ; r3 = tmpO 

mov rl,rO 

jsr get^^u ; apdu getbuffer 

Idr r3.[r2,#0] 

cmp r2,#204 

bne label! 
pop rO 

Idr rO,cst3[PC] 
jmp cardExit 

labeU : 

cs§:dl #28160 " 
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